I’ve written in the past how to use .NET assemblies in AL for your on-premise extensions and all is also officially documented here, but I think there are some tricky aspects that must be more explicited:
- In order to use your .NET assemblies (DLLs), in Visual Studio Code you need to set the assemblyProbingPaths option to point to the folders containing the assemblies that you will use.
- Visual Studio Code doeas not read the GAC by default. You have to insert the path in the al.assemblyProbingPaths option as above.
- You should always specify the Version of the assembly (at least the major version), otherwise, the compiler will pick whatever it thinks is the best match, which, depending on many factors (and sometimes this is not what you want to have).
- When you compile your project in Visual Studio Code, the compiler verifies that it can locate all the .NET assemblies you’ve referenced. When this process is successfully completed, it creates an app file containing your AL files. This app file is sent to the server where the AL files are recompiled in the server’s context. If the server’s context is missing some references, the compilation will fail and you will not be able to publish your extension (normally the error is something like
error AL0451: An assembly named 'XXX' could not be found - Remember that there is no connection between Visual Studio Code and its settings and your D365BC service instance. The server caches assembly lookups, so if you move assemblies and if you do not restart the server after moving that assemblies around or creating symbolic links, the new assemblies are not picked up (and you could have a compilation error at server side).
- The official Microsoft’s documentation says that when publishing your extension “The server will search the global assembly cache (GAC), the Add-Ins folder, and the Add-in table. You must manually install any custom assembly in one of these locations.“. It seems instead that in the current release of Business Central, the server only searches the Add-Ins folder, the Add-in table and the TempAddIns folder for assemblies. In the next release it will probe the GAC and the server’s bin folder.
Stefano Demiliani 
Thanks a lot for the above example, just wondering if you can help, any ideas, how can I reference System.Data dotnet reference in BC18 please?
LikeLike
You can do something like:
dotnet
{
assembly(System.Data)
{
type(“System.Data.DataTable”)
{
}
type(System.Data.SqlClient.SqlConnection;SqlConnection)
{
}
}
}
where type are the assemblies that you want to reference.
LikeLike
Thanks, I tried this :-
dotnet
{
assembly(System.Data)
{
Version = ‘4.0.0.0’;
Culture = ‘neutral’;
PublicKeyToken= ‘b77a5c561934e089’;
type(System.Data.SqlClient.SqlConnection; SqlConnection) { }
type(System.Data.SqlClient.SqlCommand; SqlCommand) { }
type(System.Data.SqlClient.SqlDataReader; SqlDataReader) { }
}
}
I get error on System.Data
.NET Assembly “System.Data”
An assembly named ‘System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ could not be found in the assembly probing paths ‘e:\BC18Dev\./.netpackages,”C:/Program Files/dotnet/, C:/Program Files/Assembly/, C:/Program Files/Microsoft Dynamics 365 Business Central/180/Service/Add-ins/SQLClient, C:\WINDOWS\Microsoft.NET\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089, C:\WINDOWS\Microsoft.NET\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089’
LikeLike
Thanks Stefano, I corrected al.assemblyProbingPaths, it seems have compiled OK..
LikeLike